Calling EventManager.wait_for_all_listeners_to_complete() - or closing the manager via __aexit__ - from within an event listener deadlocked. The listener runs in a task that is itself registered in _listener_tasks, so the wait ends up awaiting the very task that is awaiting it. Under a close timeout this cycle degrades further into a RecursionError.

Changes in EventManager:

• Listener tasks currently blocked in wait_for_all_listeners_to_complete() are tracked in _waiting_listener_tasks and excluded from the wait, so listener waiters never await themselves or each other. A caller that is not a listener is outside the cycle and still awaits every listener, waiting ones included.
• The wait no longer wraps the gather in an inner task. The one-tick defer that task provided is now explicit: emit only schedules the listener wrappers, and each registers its listener task once it starts running, so the wait yields before snapshotting _listener_tasks. This also drops the Event listener raised an exception. log line, which duplicated the ERROR the listener wrapper already logs with the traceback.
• The listener wrapper's finally uses set.discard() instead of set.remove(), since __aexit__ may have already cleared the task set while the listener was mid-flight (avoids a spurious KeyError).

Regression tests cover waiting from within a listener, several listeners waiting at once, closing the manager from within a listener, and waiting from outside while a listener is itself waiting.

This unblocks apify/apify-sdk-python#1061, where Actor.exit() is called from inside an event listener (e.g. an ABORTING handler) - with this fix the SDK can drop its _detach_current_listener_task workaround.

✍️ Drafted by Claude Code